Rowhammer

Known bug in DRAM chips since ~2010.

If you repeatedly charge and discharge a row in DRAM really quickly it can cause errors in nearby rows.

Manufacturers knew, but didn’t bother to document it.

• Seen as a reliability issue, not a security issue
• Cached memory largely fixes it
• Almost all RAM is vulnerable to some extent
• Maybe you could do something malicious theoretically?

Mark Seaborne and Halvar Flake (et al) discovered:

• All rows in all RAM are susceptible
• It’s the same bit flips every time when you use the same rows
• It’s even consistent between sticks from the same manufacturer!

NaCl is a sandbox that Chrome used. It checks if assembly is safe before allowing it to run.

The trick of the exploit is you flip a bit in the instruction, changing which instruction is running.

The short term fix is to ban flushing the cache in most cases. You could also get “higher quality” RAM, or refresh it more often.

Spectre/Meltdown

If we get an exception in code that was run from a failed branch prediction, we hide the exception, and undo changes to registers, reset exception flags, cancel any memory writes. However we don’t reset the cache.

This way we can force load a specific page into cache, where the page loaded depends on some memory we’re not supposed to be able to access. Then by analysing page load times, we can see which one is cached, and find the value we’re not allowed to see.

Given a few hours you could leak all memory on any system where we can run a website.

Solutions

• Disable branch prediction (100x performance decrease!)
• Disable caches (!!!)
• Disable multithreading (doesn’t solve, but makes it harder to exploit)

In the end pretty much the only real solution is to turn off multithreading.